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“La forme, c’est le fond qui revient 4 la surface.” 
“Style is the substance of the subject called unceasingly to 
the surface.” 

— Hugo 


Abstract—This report is a compilation of examples illustrating 
various types of mistakes and useful tips on how to correct them. 
The report includes the text by Mark Allman on the view of a 
referee on the process of writing papers. 


I. COMMON MISTAKES 


Here are the most common mistakes that you can easily 


avoid. 


1) 


2) 


3) 


4) 


5) 


6) 


Nouns in a nominal group are singular except the last 
one. 

WRONG: packets delivery ratio 

GOOD: packet delivery ratio 

WRONG: The simulations results show... 

GOOD: The simulation results show... 


Resist the temptation to use long strings of nouns as 
adjectives. 


WRONG: Consider the packet switched data com- 
munication network protocol problem. 


“Which” vs. “That”. 


WRONG: We present the structure of packets which 
contain the neighbor addresses. 
GOOD: We present the structure of packets that 
contain the neighbor addresses. 
More on this topic. 
“That” is the defining or restrictive pronoun, 
“which” the non-defining or nonrestrictive. 
The lawn mower that is broken is in the garage. 
(Tells which one.) 
The lawn mower, which is broken, is in the garage. 
(Adds a fact about the only mower in question.) 
If you can substitute “that” for “which”, do it. 
Punctuation in phrases with “which” and “that”. 
GOOD: All the students that know when to use 
“which” and “that” will pass the quiz. 
GooD: The exam, which took place at the begin- 
ning of class, was not difficult. 
Punctuation in enumerations. 
GOOD: It had bells and lights. 
GOOD: It had bells, whistles, and lights. 
Do not omit “that” when it helps the reader to parse the 
sentence. 
WRONG: Assume A is a group. 


GOOD: Assume that A is a group. 


7) Simplify “which is”. 


WRONG: The figure presents the time interval 
which is available for other nodes. 

GOOD: The figure presents the time interval avail- 
able for other nodes. 


8) Avoid passive voice. 


WRONG: The simulation results are presented in 
Figure 1. 
GOOD: Figure 1 presents the simulation results. 


9) Check for missing articles, particularly if your native 


tongue does not have them. Roughly, concepts and 
classes of things do not, most everything else more 
specific does. Do not use articles in front of proper nouns 
and names. 


GooD: Routers forward packets. 

GOOD: The router architecture we consider uses 

small rodents. 

GOOD: Internet Explorer is a popular web browser. 

GOOD: The current version number is 5.0. 

GooD: Bill Gates did not write Internet Explorer. 
Do not use "etc." unless the remaining items are com- 
pletely obvious. 


ACCEPTABLE: We shall number the phases 1, 3, 5, 
7, etc. 

UNACCEPTABLE: We measure performance factors 
such as volatility, scalability, etc. 


Avoid “etc.”; use “for example’, “such as”, “among 
others” or, better yet, try to give a complete list (unless 
citing, for example, a list of products known to be 
incomplete), even if abstract. 

Uncountable nouns are substances or concepts that we 
cannot divide into separate elements (e.g., advice, infor- 
mation, news, work) 


WRONG: informations, interferences 
GOoobD: information, interference 
WRONG: an information 
GOOD: a piece of information 
GOOD: the information 
Possessive ’s. Concerns persons not things. 
WRONG: packet’s size 
GOOD: packet size 
Allow. Permit. Permit is more formal than allow. Enable. 
GooD: They do not allow smoking here. 


15) 


16) 


17) 


18) 


19) 


20) 


21) 


22) 


GooD: They do not allow us to smoke here. 

GooD: They do not permit smoking here. 

GooD: They do not permit people to smoke here. 

GOOD: It enables nodes to detect collisions. 

No articles before symbols. 

WRONG: Based on the distance d, we can com- 

pute... 

GooD: Based on distance d, we can compute... 
Symbols in different formulae must be separated by 
words. 

WRONG: Consider Sy, q < p. 

GooD: Consider S4, where q < p. 

Indices of variables are only written in italics if they 
represent another variable, but not if they are just an 
abbreviation of a word ( use \mathrm (math roman) 
in the equation). 

WRONG: Umar = 120 km/h. 

GOOD: Vmax = 120 km/h. 

Sv_{\mathrm {max} }=120$~km/h 

GOOD: v; = 120 km/h. 

Protocol abbreviations typically do not take an article, 
even if the expanded version does. 

Goop: The Transmission Control Protocol delivers 

a byte stream. 

GooD: TCP delivers a byte stream. 

Goon: The TCP design has been successful. 

Check that abbreviations are always explained before 
use. 

WRONG: IEEE has developed a standard for LR- 

WPANSsS. 

GooD: IEEE has developed a standard for Low- 

Rate Wireless Personal Area Networks (LR- 

WPANS). 

Linking words. 

WRONG: Firstly, we construct...Secondly, we de- 

velop... 

GooD: First, 

velop... 


we construct...Second, we de- 


Sections and figures. Do not use the word “Subsection”; 
use “Section” and write out the complete citation. 

WRONG: In section 5, we show... 

GooD: In Section 5, we show... 

GooD: In Section II-A, we show... 

WRONG: We can see in figure 5... 

GooD: We can see in Figure 5... 

but 

GooD: We will explain in the section that... 

GooD: We can see in the figures that... 
The text should make sense if we read through it 
omitting the titles of subsections. 

WRONG: 2. Contour Integration. This technique, 

invented by Cauchy, defines... 

Goon: 2. Contour Integration. The technique of 


23) 


24) 


25) 


26) 


27) 


integrating along curves in the complex plane, 
invented by Cauchy, defines... 
Bibliographic references are not nouns. The phrase 
needs to make sense if you delete them. 
WRONG: The authors in [7] proposed the best 
protocol for flooding. 
GOOD: Jain et al. proposed the best protocol for 
flooding [7]. 
WRONG: In [7], Jain et al. proposed the best 
protocol for flooding. 
GOOD: Jain et al. proposed the best protocol for 
flooding [7]. 
“et al.’ stands for “et alia” and means “and others”. 
You can use it for citing the papers with more than 
two authors. “et al.” is not italicized nor underlined. 
TeX assumes thet a period ends a sentence unless it 
follows an uppercase letter. So, put a \_ (where _ means 
“space”) in a sentence like “Smith et al. say that ...”. 
WRONG: Doe et al. proposed the best routing 
protocol [1]. 
[1] John Doe “Optimal Routing Protocol’, Proc. 
Infocom 2002. 
GooD: Doe et al. proposed the best routing proto- 
col [1]. 
[1] John Doe, Frank Sinatra, and Bruce Lee “Op- 
timal Routing Protocol”, Proc. Infocom 2002. 
GooD: Doe and Sinatra proposed the best routing 
protocol [1]. 
[1] John Doe and Frank Sinatra “Optimal Routing 
Protocol’, Proc. Infocom 2002. 
Capitalize titles (common practice in the US). To keep 
titles capitalized use double {{ }} in a BibTeX item: 


Title = {{Geographical Routing Using Partial 
Information for Wireless Ad Hoc Networks}}, 


WRONG: Classifying service flows in the encrypted 

skype traffic. 

GooD: Classifying Service Flows in the Encrypted 

Skype Traffic. 
In Britain, typographers use in headlines exactly the 
same capitalization rules as in normal sentences, namely 
only the first word and proper nouns or abbreviations are 
capitalized. You need to protect all proper nouns (names) 
and abbreviations by surrounding {} in your BibTeX file. 
Adverbs before verbs. 

WRONG: The protocol operates usually in indoor 

environments. 

GOOD: The protocol usually operates in indoor 

environments. 


99 cos 


Frequent repetition of a word like “this”, “they”, “just”, 
or “then”. 

Avoid nonreferential use of “this”, “that’’, “these”, “it”, 
and so on. Requiring explicit identification of what 
“this” refers to enforces clarity of writing. Here is a 
typical example of nonreferential “this”: 


28) 


WRONG: Our experiments test several different 

environments and the algorithm does well in some 

but not all of them. This is important because... 
Use strong verbs instead of lots of nouns and simple 
terms rather than fancy-sounding ones. 

WRONG: make assumption 

GOOD: assume 

WRONG: is a function of 

GooD: depends on 

WRONG: is an illustration 

GoobD: illustrates, shows 

WRONG: is a requirement 

GOOD: requires, needs to 

WRONG: utilizes 

GOOD: uses 

WRONG: had difference 

GOOD: differed 


II. VARIOUS TIPS 


Here is a compilation of several tips on writing style [1], 


[2], [3]: 


1) 
2) 


3) 
4) 


5) 
6) 
7) 


8) 


9) 


Avoid words like “this” or “also” in consecutive sen- 
tences. 
Use “Eq. 7”, not “Equation (7)”, unless you need to fill 
empty pages. 
Don’t start sentences with “That’s because”. 
In formal writing, contractions like “don’t”, “doesn’t”, 
“won't” or “it’s” are generally avoided. 
Be careful not to confuse “its” with “it’s” (it is). 
Avoid cliches like “Recent advances in ...”. 
Writing units. Units are always in roman font, never 
italics or LaTeX math mode. There is a nonbreaking 
space between the measurement and the unit. The unit 
is not italicized. The space between the two should 
be a thin space (e.g., 10~m in LaTeX). You can use 
siunitx package (\SI{10}{m}) which can easily 
change style if desired. (Reference, from NIST, and 
TUGboat article on typesetting math) 
GOOD: to say ten meters: 10 m. The LaTeX ex- 
pression \ST{10}{m} results in the following 
formatting: 10 m. 
WRONG: to say ten meters: 10m or 10m. 
Use “kb/s” or “Mb/s”, not “kbps” or “Mbps”—the latter 
are not scientific units. Be careful to distinguish “Mb” 
(Megabit) and “MB” (Megabytes), in particular “kb” 
(1,000 bits) and “KB” (1,024 bytes). 
Note the difference between “i.e.” and “e.g.”, which 
contrary to popular belief are not synonymous: “id 
est” means “that is” and “exempli gratia” means “for 
example”. “e.g.” and “i.e.” are not italicized, and always 
followed by a comma. 
GOOD: ...real-time streaming video (e.g., Skype 
and Facetime). 
GOOD: ...upward communication (i.e., the nodes 
transmit to the base station) 


10) 


11) 
12) 


13) 


14) 


15) 


16) 


17) 


18) 


19) 


20) 


Avoid excessive use of “i.e.”. Vary your expression: 
“such as”, “this means that’, “because”, .... “i.e?” is 
not the universal conjunction! 
Do not use ampersands (&) or slash abbreviations (such 
as s/w or h/w) in formal writing. 
“Respectively” is preceded by a comma, as in “The light 
bulbs lasted 10 and 100 days, respectively.” 
“Therefore”, “however”, “hence”, and “thus” are usually 
followed by a comma, as in “Therefore, our idea should 
not be implemented.” 
Never use “related works” unless you are talking about 
works of art. It’s “related work”. 
Do not refer to colors in graphs. Most people will print 
the paper on a monochrome (black and white) printer 
and will have no idea what you are talking about. Make 
sure that graph lines are easily distinguishable when 
printing on a monochrome printer. 
Use hyphens for concatenated words: “end-to-end ar- 
chitecture”, “real-time operating system” (but “the com- 
puter may analyze the results in real time”), “per-flow 
queueing”, “flow-enabled”, “back-to-back”, ... 
Compound adjectives are two or more words that to- 
gether make an adjective. When they come directly 
before a noun, they are known as compound modi- 
fiers and usually have a hyphen. Use of a hyphen: 
“high-performance” is hyphenated because “high” mod- 
ifies “performance” not “implementation”. Here, “high- 
performance” is an adjective. But: “Our implementation 
has high performance.” Here, “performance” is a noun. 
No hyphen. Similarly: “throughput-oriented workloads” 
or “GPU-based implementation”. 

GooD: “We built a high-performance implementa- 

tion.” 

GooD: “This is a well-written article.” 

GooD: “This article is well written.” 
Don’t overuse dashes for separation, as they interrupt 
the flow of words. Dashes may be appropriate where 
you want to contrast thoughts very strongly or the dash 
part is a surprise of some sort. Think of it as a very long 
pause when speaking. In many cases, a comma-separated 
phrase works better. If you do use a dash, make sure 
it’s not a hyphen, but an em-dash. Distinguish between: 
hyphen (-), minus (—, $-$), en-dash (-, - -) and em-dash 
Cee 

GOOD: Learn to use the em-dash—it is a good 

friend. 
“While” instead of “and”, “but”, “although”. In general 
“while” should be used only in the strict sense of “during 
the time time”; so search for “while” in your text to see 
if the sentence is about time or could be replaced with 
“although”. 
Provide sufficient information in the caption of a figure 
so that the reader does not need to look for the descrip- 
tion in the text. 


GooD: Figure 5. Outstanding data (cwnd) and 


21) 


22) 


23) 


queue size at RI and R2. Equal buffer size 
(30,000 B) on both sides. The downlink buffer 
remains empty for significant periods of time, 
whereas the uplink buffer never empties. 


Motivate the reader for what follows. Perhaps the most 
important principle of good writing is to keep the reader 
uppermost in mind: What does the reader know so far? 
What does the reader expect next and why? 

Get the attention of your readers immediately. Snappy ti- 
tles, arresting first sentences, and lucid initial paragraphs 
are all methods of doing this. 

Don’t use the same notation for two different things. 
Conversely, use consistent notation for the same thing 
when it appears in several places. 


III. TERMS AND PHRASES TO AVOID 


Douglas Comer gives this list of terms and phrases to avoid 
in a PhD dissertation [4]: 


adverbs 


Mostly, they are very often overly used. Use strong 
words instead. For example, one could say, “Writers 
abuse adverbs.” 


e jokes or puns 


They have no place in a formal document. 
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“bad”, “good”, “nice , 


9 66 


terrible”, “stupid” 


A scientific dissertation does not make moral judge- 
ments. Use “incorrect/correct” to refer to factual 
correctness or errors. Use precise words or phrases 
to assess quality (e.g., “method A requires less 
computation than method B”). In general, one should 
avoid all qualitative judgements. 
“true”, “pure”, 
In the sense of “good” (it is judgemental). 
“perfect” 
Nothing is. 
“an ideal solution” 
Yov’re judging again. 
“today”, “modern times” 
Today is tomorrow’s yesterday. 
“soon” 
How soon? Later tonight? Next decade? 
“we were surprised to learn...” 
Even if you were, so what? 


39 66 


“seems”, “seemingly”, 
It doesn’t matter how something appears. 
“would seem to show” 
All that matters are the facts. 
“in terms of” 
Usually vague. 
“based on”, “X-based”, “as the basis of” 


Careful; can be vague. 


e “different” 

Does not mean “various”; different than what? 
e “in light of” 

Colloquial. 
e “lots of” 

Vague and colloquial. 
e “kind of” 

Vague and colloquial. 
e “type of” 

Vague and colloquial. 
e “something like” 

Vague and colloquial. 
e “just about” 

Vague and colloquial. 
e “number of” 


9 66 


Vague; do you mean “some”, “many”, or “most”? A 
quantative statement is preferable. 


e “due to” 
Colloquial. 
e “probably” 


Only if you know the statistical probability (if you 
do, state it quantatively). 

e “obviously, clearly” 
Be careful: obvious/clear to everyone? 

e “simple” 
Can have a negative connotation, as in “simpleton”. 

e “along with” 
Just use “with”. 

e “actually, really” 
Define terms precisely to eliminate the need to 
clarify. 

e “the fact that” 
Makes it a meta-sentence; rephrase. 

e “this”, “that” 
As in “This causes concern.” Reason: “this” can refer 
to the subject of the previous sentence, the entire 
previous sentence, the entire previous paragraph, 
the entire previous section, etc. More important, it 
can be interpreted in the concrete sense or in the 
meta-sense. For example, in: “X does Y. This means 
...” the reader can assume “this” refers to Y or to 
the fact that X does it. Even when restricted (e.g., 
“this computation. ..”’), the phrase is weak and often 
ambiguous. 


e “You will read about...” 


The second person has no place in a formal disser- 
tation. 


e “I will describe...” 


The first person has no place in a formal dissertation. 
If self-reference is essential, phrase it as “Section 10 


describes...” 

“we” as in “we see that” 
A trap to avoid. Reason: almost any sentence can be 
written to begin with “we” because “we” can refer 
to: the reader and author, the author and advisor, 
the author and research team, experimental computer 
scientists, the entire computer science community, 
the science community, or some other unspecified 
group. 

“Hopefully, the program...” 
Computer programs do not hope, not unless they 
implement AI systems. By the way, if you are 
writing an AI thesis, talk to someone else: AI people 
have their own system of rules. 

“...a famous researcher...” 


It does not matter who said it or who did it. In fact, 
such statements prejudice the reader. 


Be careful when using “few, most, all, any, every”. 


material doubles as an outline of the rest of the paper, saving 
space and eliminating redundancy. 


V. FINAL TRUTHS 


Some handy maxims (notice that each sentence below is 
“wrong” in the sense that it illustrates bad usage): 


e Watch out for prepositions that sentences end with. 
e When dangling, consider your participles. 

e About them sentence fragments. 

e Make each pronoun agree with their antecedent. 

e Don’t use commas, which aren’t necessary. 

e Try to never split infinitives. 


Put yourself in the reader’s place! Ask yourself what the 
reader knows and expects to see next at some point in the 
text. 

Do organize and do not distract. 

Bad writing comes from bad thinking, and bad thinking 


A dissertation is precise. If a sentence says “Most 
computer systems contain X”, you must be able to 
defend it. Are you sure you really know the facts? 
How many computers were built and sold yesterday? 


e “must”, “always” 
Absolutely? 
e “should” 


Who says so? 
e “proof”, “prove” 

Would a mathematician agree that it is a proof? 
e “show” 


Used in the sense of “prove”. To “show” something, 
you need to provide a formal proof. 


e “can/may” 
Your mother probably told you the difference. 


IV. WRITING THE INTRODUCTION TO A PAPER 


There are a lot of good tips for writing papers [5], [6], [7], 
[8], [9], [10], [11], [12], [13], [14], [15]. As “Abstract and 
Introduction are the most important sections” [16], here are 
just some clues about writing introductions. 

Unless there is a good argument against it, the Introduction 
should consist of five paragraphs answering the following five 
questions [5]: 

1) What is the problem? 

2) Why is it interesting and important? 

3) Why is it hard? (e.g., why do naive approaches fail?) 

4) Why has not it been solved before? (Or, what’s wrong 

with previous proposed solutions? How does mine dif- 
fer?) 

5) What are the key components of my approach and 

results? Also include any specific limitations. 

Then, have a final paragraph or subsection: “Summary of 
Contributions”. It should list the major contributions in bullet 
form, mentioning in which sections they can be found. This 


never produces good writing. 
Easy writing makes damned hard reading. 
Less is more. 


Mais malheur à l'auteur qui veut toujours instruire ! Le 


secret d’ennuyer est celui de tout dire. 


Here are the comments of Mark Allman quoted inline [17]. 
They are specific to the Networking community, but most of 


Voltaire, De la Nature de l Homme. 


VI. MARK ALLMAN’S PLEA 


the remarks also concern other domains. 


I have just completed my first (maybe only!) stint on 
the program committee for the ACM SIGCOMM an- 
nual symposium. While I have refereed many papers 
over the years I have never before read so many sub- 
missions in such a short span of time (I filed 20 re- 
views within about a month and read/skimmed many 
more papers). This experience was eye-opening in 
that I now realize that the community generates a 
large amount of junk. And, I don’t mean “junk” 
in the sense of bad ideas. In general, each paper 
I reviewed for SIGCOMM this year had at least a 
nugget of an interesting idea. I mean “junk” in the 
“it took me twice as long to read this as it should 
have” sense. In other words, the paper was sloppy. I 
had a very difficult time trying to figure out what the 
paper was proposing or what the experiments were 
really showing. The following is a short list of easy 
ways to improve your research papers. 

Most of the following comments are general and I 
presume would apply to any situation in which one 
is attempting to publish scholarly work. However, 
the last comment is directed specifically at the 
internetworking research community. 


1 


A. Fire Up the Spell Checker, Please! 


I cannot spell either. I have, however, mastered 
ispell. It seems to me that everyone has access to 
a good spell checker these days. Not using the spell 
checker just indicates that either you are sloppy or 
you do not care. If you’re sloppy with your writing 
why should I believe you are not sloppy with your 
experiments/analysis as well? If you don’t care about 
your paper, why should I? 


B. Sloppy Papers Are Long Shots 


Proofread your paper. I see lots of mistakes that 
indicate the paper was not looked over before it 
was submitted (e.g., “The foo algorithm works better 
than the the bar algorithm.’). Again, if you do not 
take enough care in presenting your work, why 
should I be compelled to recommend accepting it? 
Sloppy papers give the indication of sloppy research. 
As well as reflecting poorly on your work, such pa- 
pers are often very difficult to read and understand. 
Presumably, the point of writing a paper is to convey 
new information to the world. Therefore, there is 
major value in clear writing. If a referee can’t get 
the point of the paper, or has a very difficult time 
getting the main idea, there is a high likelihood that 
the paper will be rejected. 


C. I Read Submissions in My Lazy Boy 


I print out all papers I review. I read them in 
my lazy boy!. I scribble notes on them. Do not 
assume that I am looking at color plots! Color is 
certainly nice and helps out immensely in conference 
presentations. But, color plots come out of my black 
and white printer very badly in most cases. Besides, 
most conferences/journals publish black and white 
papers. Make it easy for my weary eyes to tell the 
difference between the lines on your plots. Do not 
plot on a grey background. Make the font on the 
plots readable without a magnifying glass. Help me 
out! Please! 

Often the plots are key to understanding the paper. 
And, at the risk of being redundant: If I cannot 
understand the paper I will recommend rejecting it. 


D. Don’t Waste My Time I 


You do not need to give an in-depth tutorial of all 
background material. I cannot give you a good rule 
of thumb to help you know how much background 
material to include. It depends on the conference 
to which you are submitting, the maturity of the 
background work, etc. But, I can tell you that 
there are some topics (e.g., TCP congestion control) 
that are well understood by people attending any 
networking conference. You do not need to describe 


a comfortable coach 


the algorithms in painful detail. A short paragraph 
re-capping the main ideas and providing references 
to the original works should suffice. 


E. Don’t Waste My Time IT 


You do not need to provide me with an example 
of every kind of plotting strategy you use. When 
you first show a plot with notation that I might not 
understand, explain the notation. But, using half a 
page to show me a plot that adds nothing to my 
understanding of the topic is a less than compelling 
use of real estate. 


F. Don’t Waste My Time III 


Roughly stick to the page limit and the requested 
format. Don’t make me try to guess how long your 
paper really is because you 1.75-spaced the paper 
rather than double-spacing it as requested in the call 
for papers. 

(Note to program committee chairs and journal edi- 
tors: This reviewer’s opinion is that if a submission 
is not obviously in the ball-park of the page limit it 
should be immediately returned to the authors until 
such time that it is in the ball-park.) 


G. Answer All the Easy Questions 


If you need a constant for the foo algorithm and you 
define c = 17, I want to know why you chose 17. 
Also, some items in papers jump out at reviewers 
as odd. For instance, I was recently reviewing a 
paper that simulated a network with a bottleneck 
bandwidth of “about T1 rate”. The actual rate of 
the link turned out to be something like 1.3 Mbps. 
This begs the obvious question of why the authors 
used 1.3 Mbps rather than using T1 rate (1.5 Mbps). 
Even if the explanation you end up with is rough, 
it is better than no explanation at all in the vast 
majority of the cases. 


H. Make My Life Easy 


It is not a super-big deal, but it is always nice to get 
a paper that is easy to read. This includes things like 
using a very clear font that is of readable size and 
numbering the pages. 


I. A Little Restraint, Please 


Your paper does not solve the entire world network- 
ing problems. Really. Many papers rub reviewers the 
wrong way by making bold claims about solving 
all sorts of problems without any sort of evidence 
(or only weak evidence). It is much better to show 
some restraint and perspective when discussing your 
results. It is alright to solve small problems, or to 
only show preliminary results that may indicate a 
solution. Just don’t over claim what you have shown. 


J. Use Units 


“The length of our data transfers is 1” means noth- 
ing. 1 what? 1 packet? 1 KB? 1 minute? Sometimes 
it is obvious from the context—sometimes it isn’t. 
If you use units you don’t have to worry about it. 


K. We’re All Not Mathematicians 


Theorems are quite a necessary part of many papers. 
However, it is not necessary to give only a theorem 
with no summary or context. Summaries aid me as 
a reviewer to gain an intuitive understanding before 
trying to dig into the math to make sure what you 
have it correct—thus making my task easier and less 
error prone, I believe. As a reader of a paper, I often 
just want the high-order bit without slogging into the 
theorems and proofs to get said bit. 


L. On References 


One common mistake that authors make is failing to 
include relevant references. It is better to err on the 
side of citing too much related work. 

Next, when previous work must be criticized, do so 
in a constructive manner. In other words, do not say 
something like “Zevon’s [1] work is easily shown 
to be less effective than the work presented in this 
paper”. Mr. Zevon might be reviewing your paper! 
Something more along the lines of: “Zevon [1] first 
introduced the foo algorithm for decreasing the size 
of routing tables. We show a more robust algorithm, 
bar, that goes a step further and reduces the size of 
routing tables by 50% when compared to the foo 
algorithm.” 

Finally, do not overstate what a paper you are citing 
says. It is often better to stick with the author’s 
conclusions and not come up with your own. For 
instance, many times I see simple simulation studies 
cited as “proving” the algorithm in question is safe 
and works well for the entire Internet. If one goes 
back to the original paper the conclusion is not 
nearly as bold, often claiming that the simple simula- 
tions are an indication that the algorithm is workable 
and that future work on testing the algorithm in the 
Internet is needed. Overstating previous work may 
make your argument stronger if you are not caught. 
But, when I notice such references they cast your 
paper in a not-so-wonderful light in my eyes. 


M. Read These Papers 


I have noticed that a number of other reviewers are 
including pointers to the papers on TCP [18] and on 
simulating the Internet [19] in their reviews. They do 
not necessarily provide hard-and-fast rules for how 
to conduct research. However, they do provide some 
collected wisdom that should at least be considered 
in your research efforts. 


In addition, the note by Partridge provides specific 
guidance on getting a paper accepted for presenta- 
tion at SIGCOMM [20]. 

I don’t want to make it sound like I think you 
need to write perfect papers when submitting to a 
conference or journal. A mis-spelling here or there, 
an extra word, an extra page, etc. are all OK. They 
will not be cause for your paper to be rejected. But, 
it is surprising how often authors make many of the 
mistakes listed above in a single submission. The 
bottom line is that if it is difficult for me to make it 
through your paper (because the writing is poor or 
I can’t read the plots or whatever) there is a higher 
chance that I will err on the side of recommending 
that the paper be rejected. Furthermore, the above 
items are easy things to fix when compared with the 
hard task of conducting your investigation. As I said 
in the opening, I believe most of the papers I review 
have a decent idea — yet I recommend rejecting the 
vast majority of the papers I review. I believe many 
papers would have a much better chance at being 
accepted if the authors simply take a little more time 
in preparing their manuscript. 


VII. CONCLUSIONS 


After reading all this stuff, you may think that some remarks 
are contradictory. Yes, maybe—use your common sense to 
choose the right word, or better check on the Internet. 

Good writing requires practice. A good starting point is 
to read well written papers, analyze, and use them as an 
inspiration. 


[1 


[2 
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